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ABSTRACT 


In this thesis we present a conceptual database for 
ROKAF's Personnel Management, based upon the relational data 
medel. the objective of this thesis is to apply the 
computerized personnel information system to the area of 
military officer personnel management. A database design 
methodology which utilizes miltiple levels of conceptual and 
Heertcal database design structure 1s presented. We discuss 
the logical schema design in eons of a stepwise, interactive 
Mmme@eess OL Specification and refinement. We present 
operations to manipulate the relational data model for end- 
users data base processing during the integration process. 

The logical database is intended for use within a 
relational database system. This model has been tested 
using ORACLE, a relational database management (DBMS) 
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I. INTRODUCTION 


Simrentiy, the ROK Air Force Computer Center is 
developing a personnel data system with emphasis on 
collecting data and processing and presenting information to 
users in each staff department. But the collected data does 
Mot include all of the personnel data elements. Furthermore, 
ieeemall) Of the collected data have been identified as data 
ewements. 

In order to strengthen the readiness of the ROK Air 
Force under the limited national defense expenditure, it is 
mipetative that personnel management be performed very 
efficiently and that all data in connection with Combat 
Meewerecords and, in particular, for individual Pilot 
Quality Control (IPQC), be analyzed and integrated. To 
achieve this goal, the high level managers of Combat and 
Command (CAC) and Air Force Headquarters very often need a 
femme ty Of data relevant to each personnel. This situation 
motivates the ROKAF to develop a modern database system. 

A most important consideration in database development 
mmmpeormstore data so that it can be used for a wide variety 
of applications and can be changed quickly and easily. In 
Sager CO perform these functions, the data should be 
imeependent and functionally dependent on key values. It 


Se@euld also be possible to query the database to satisfy 
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user's requirements using application programs or the 
Database Management System (DBMS) itself. These data items 
should contain useful information for decision makers to 
analyze, plan and manage a personnel organization. 

It 1s very difficult to develop a database which 
performs in an optimal fashion. There are many different 
Ways in which data can be structured and each has its own 
advantages and disadvantages. Different users want to use 
different data. It is hardly possible to satisfy all of the 
users with one type of data organization. The normal form 
@oncepts of relational database models will be applied to 
develop a database for CAC and Air Force Headquarters 
personnel management. The relational data model supports 
data independence better than other models. 

To use these databases for personnel management 
purposes, a commercially available database management and 
an end-user application system are needed. This thesis will 
Mmi@ererore focus on a preliminary personnel reiational 
database system. In chapter II, we discuss the general 
overview of a database system and a relational data model. 
imechapter III, we analyze the system requirements and 
develop the ROKAF personnel management database which 
includes all data and an end-user application system to 
extract useful data for the manager of CAC and Air Force 
headquarters. This chapter includes implementation of the 


developed database using ORACLE, a relational database 
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Meamagement System. Finally, in chapter IV, we present 
conclusions and recommendations based on the research 


Mresented in the thesis. 


II. BACKGROUND 


A. SYSTEMS ANALYSIS AND DESIGN 

A system can be very simply and broadly defined as a 
mom Of interrelated or interacting elements. However, a 
Meme specific and appropriate concept of a system is 
utilized in data processing and computer technology. A 
system can be defined as a group of interrelated components 
that seeks the attainment of a common goal by accepting 
inputs and producing outputs in an organized transformation 
precess.{Ref. 1] 

Figure 2.1 illustrates the systems approach as a 
"recycling" process of systems development. This model 
summarizes the stages of the systems development cycle and 
can be applied to all systems. The “testing cycle" involves 
testing the model or system and performing any necessary 
redesign, reprogramming, and retesting activities. The 
"maintenance cycle" involves performing the systems 
development activities required to improve an established 
System. 

ie oystems Analysis 

Systems analysis involves analyzing in detail the 
information needs of prospective users and developing the 
system requirements of the proposed systems. The goal of 


systems analysis is to produce the system requirements of 
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The Systems Development Cycle 


mienproposed database system. The system requirements 


describe the data processing and information requirements of 
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the proposed database system and are developed by a detailed 
am@alysis of (1) the organization that will use the system, 
my the information requirements of the user organization, 
and (3) the database system presently used, if any. The 
systems analysis stages are given below: 

Phase l - organization system analysis 

Phase 2 - major subsystem analysis 

Phase 3 - present database system analysis 

Phase 4 - proposed database system analysis 

Phase 5 - system requirements 

me systems Desien 

Systems design involves the development of a logical 

and physical design for a database system that meets the 
system requirements developed by the systems analysis 
process. Systems design involves the detailed design of 
input documents, output reports, database, and processing 
procedures. Personnel, data media, equipment, and 
programming specifications are also developed for the 
Beaposed system. Typical systems design steps are as 
follows: 

Phase 1 - logical system design 

Phase 2 - physical system design 


Phase 3 - system specification 


ES 





B. OVERVIEW OF A DATABASE SYSTEM 
Paeireroane clon 
Terminology for database systems is still not 
Standardized. Different database systems employ different 
words to describe data and relationships. [{Ref. 2] Therefore, 
confusion has arisen over the description of a database. 
However, it is to some extent accepted as conveying a more 
meenisticated concept than the older term "file." File 
processing systems are predecessors of database systems. 
They do not allow integrated processing.{Ref. 3] In order 
to develop a relational database system and to apply it, the 
general terminology and basic concepts must be understood by 
users and designers. This chapter covers the basic concepts 
of database system architecture, the relational data model, 
and database security. 
Ee basic Concept of a Database System 
a. Data versus Information 

Data and information are meant to have two 
distinct meanings. Data refers to facts collected from 
observations or measurements, or to values physically 
recorded in a file or database. Information refers to the 
meaning assigned to those facts and values as a result of 
interpretation of data. Data are processed into information 
so that it can be understood and employed by users.[Ref. 1] 

In some cases, data may not require processing 


before constituting information for a human user. However, 
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feteaeare usually mot useful until they have been subjected 
to a process where their form is manipulated and organized 
Bea, their content is analyzed and evaluated. Then data 


become information. Figure 2.2 shows this relation. [Ref. 1] 








Aen ts Salesperson: J. Jones 
$35,000 Sales Territory: 
Jones Western Region 
$12,000 Data Current Sales: 
Pr@cess rid 
Western Region st LG) LONG 
POOR Miar es 147 units 
$100,000 
S55 Units 
Data Information 


picumew..2 wedta Versus Information 


b. Database 

A database may be defined as a collection of 
data and data structure. There are two different databases: 
the physical database and the conceptual database. 

The physical database resides permanently on 
secondary storage devices such as disks and tapes. We may 
view the physical database itself at several levels of 
abstraction, ranging from that of records and files ina 


programming language such as Pascal, through the level of 





logical records as supported by the operating system 
underlying the DBMS, down to the level of bits and physical 
addresses on storage devices. 

The conceptual database is an abstraction of the 
real world pertinent to an enterprise. A DBMS provides a 
data definition language to specify the conceptual schema 
and, most likely, some of the details regarding the 
transformation of the conceptual schema into the physical 
mepresentation. 

c. Database System 

A database system 1S a combination of databases, 
a DBMS, and optionally an application system which is a 
@erlrection of end-user application programs. C. J. Date 
[Ref. 4] defines a database system as a computer-based 
recordkeeping system; a system whose overall purpose is to 
record and maintain information. The information concerned 
can be anything that is deemed to be of significance to the 
Organization. Figure 2.5 shows a greatly simplified view of 
a database system consisting of four major components: data, 
hardware, software, and users. 

CUM lard eel iececdatal stored 1n the system 1S 
partitioned into one or more databases. A database system 
has several important advantages that accrue from having 
centralized control of the data. These are verified in 


Reference 4 as described below: 
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(Repmanted from (Ref. 4] } 


Figure 2.3 Simplified Database System 


Micmaatancan pe shared. this reduces the time needed 
to develop new systems or to respond to one-of-a-kind 
meguests well Chtecc, MOTre infOrmation can be obtained 
from existing data. 

Redundancy can be reduced. This is the elimination 
or reduction of data duplication that can lead to 

a lack of data integrity in conflicting reports. 
Inconsistency can be avoided. If a given fact is 
represented by a single entry, then inconsistency 
eannot OCeur. 

reahaiLusmeam pe emtmorced. With central control 


of the database, the Database Administrator (DBA) 
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can ensure that all appiicable standards are 
fOLLowed Im the representation of the data. 

Mmemoccurity restructions can be applied. The DBA can 
ensure that the only means of access to the database 
US through the proper channels, and Thome can define 
Plienontzat ron cheeks to be Carried out whenever 
access to sensitive data is attempted. 

See integrity can be maintained. The problem of ensuring 
that data in the database are accurate can be avoided 
byepetmitting the DBA to define validatiom procedures 
Gombe GCauricad OUC wWhemever anySupdate operation 
Mom bheempued . 

(2) Hardware. The hardware consists of the 
secondary storage voiumes (disks and drums) on which the 
database resides, together with the associated devices, 
Semerol units, channels, and so forth. 

(Sjesoftware. Between the physical database 
meself and the users of the system is a layer of software, 
usually called the Database Management System or DBMS. 

A DBMS is an operating system for data that 
allows one or many persons to use and modify databases. A 
major role of the DBMS is to allow the user to deal with 
the data in abstract or logical terms, rather than as the 
Gemputer stores the data. In this sense, the DBMS acts as an 


Mmimeer preter for a high-level programming language. 
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Pomoc tom iiculisers generally fall into three 
merefrOriecs. First, there is the application programmer, 
responsible for writing application programs that use the 
@atabase, typically in a language such as COBOL or PL/I. 

The second class of user, is the end-user, 
accessing the database from a terminal. An end-user may 
employ a query language provided as an integral part of the 
system, or (s)he may invoke a user-written application 
program that accepts commands from the terminal and, in turn, 
issues requests to the DBMS on the end-user's behalf. 

Miewthtrd Glass Of Wser is the database 
fomamistrator, or DBA. A high-level person, generally called 
a DBA, is granted responsibility for matters that deal with 
the database as a whole, while individual queries and 
fantoulations of the database are handled by the application 
programmers and users. The DBA's major responsibilities 
miclude determination of information content and access 
strategy, interfacing with users, performance monitoring, 


and defining crisis procedures for backup and recovery. 


Cd 


me Amn Architecture for a Database System 


The architecture is divided into three general 
Mmeeers: internal, conceptual and external.[Reft. 4] The 
mmieernal level is the one closest to physical storage, that 
is, the one concerned with the way in which the data are 
actually stored. The external level is the one closest to 


users, that is, the one concerned with the way in which the 
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data are viewed by individual users. The conceptual level 


may be thought of as defining a community user view. 


external level a 
(individual user view) ehaue 6 6 «6 caeutee 
conceptual level 
(community user view) 
internal level 
(storage view) 


Figure 2.4 The Three Levels of Architecture 


meee RELATIONAL DATA MODEL 
ie 6 lmtroduction 
A data model based on relations and their 
representation as tables was first proposed by Codd.[Ref. $] 
In the formulation of relational data models, the 
mathematical theory of relations is extended logically where 
required to meet data management objectives. The 


mathematical foundation of relational data models permits 


meecant and concise definition and deduction of their 


Mmeoperties.[(Ref. 6] 
wee 6vocructure 
The only data structuring tool used by relational 


data models is a relation. The definition of a relation in 
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the relational data model is identical to the mathematical 
definition except that database relations are time varying. 
That is, tuples are inserted, deleted, and modified in 
database relations. The intension of a relational database 
is specified by a relational schema which consists of one or 
more relation schemes. A relation scheme is a listing of a 
relation name and its corresponding domain names, which can 
Memused tO represent an entity type in relational data 
models. Since relational data models are table data models, 
@erelational schema does not reflect explicity all the 
relationships between relations in the database. 
es 6<Constraints 

A relation may have several keys. To eliminate the 
trivial keys, a key of relation must satisfy the following 
two properties.[Ref. 7] 

1. Unique Identification. In each tuple of the 
Pelavlenmeme value of the key uniquely identifies 
each tuple, that is, no two rows have the same value 
for the attributes in the key taken as a whole. 

meee nonredundancy. No attributes that are part of the 
Key can be removed without destroying property 1, 
that is, the key is minimal. 

4. Query Language 
Query languages for the relational model break down 


into two broad classes: 
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imoenieebrarc languages where queries are expressed by 
applying specialized operators to relations, and 

2. Predicate calculus languages, where queries 
describe a desired set of tuples by specifying a 
Hredicate tne tuples must Satisfy. The calculus- 
based languages have two classes, depending on 
whether the primitive objects are tuples or are 
elements of the domain of some attribute. 

Each of the abstract query languages is equivalent 
in expressive power to the others and were first proposed by 
Meda (Ref. 8] to represent the minimum capability of any 
reasonable query language using the relational model. 

Examples of the typical query languages are: 

1. ISBL (Information System Base Language) is a query 
language developed at the IBM United Kingdom 
Selentitie Center im Peterlee, England, for use in 
WicmexDelaMnMentalsretenlec Relational Test Vehicle 
(PRTV) system. 

meOUEL is the query language of INGRES, a relational 
DMBS developed at the University of California, 
Berkeley, to run under the UNIX operating system, a 
Eupte "calculus language. 

3. Query-by-Example (QBE) is a language developed at IBM, 


a domain calculus language, Yorktown Hts. 
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De DATABASE PROTECTION 
Poemocecun lt y 
The subject of database security involves the 
mmeercction of the database from unauthorized access. First, 
we need to protect against both undesired modification and/ 
or destruction of data and against unauthorized reading of 
data. Three techniques are described below: 

1. User Identification. The most common scheme to 
identify users is a password known only to the system 
and the individual. 

@mm__oiivysiea: Protection. A high security system needs 
better identification that a password, such as 
mensonaterecocn@£i10n of the user by a guard. 

5. Maintenance and Transmittal of Rights. The system 
needs to maintain a list of rights enjoyed by each user 
Sie cde protected portion of the database. 

we imteerity Preservation 
This aspect concerns nonmalicious errors and their 
prevention. The DBMS can help detect some programming bugs, 
Such as a procedure that inserts a record with the same 
Values in the key fields as a record that already exists in 


the database. 
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T¥i., DATABASE AND APPLICATION SYSTEM DEVELOPMENT 


Pee USER REQUIREMENTS SPECIFICATION 
fe introduction 

The ROK Air Force uses the general staff system of 
the USAF, namely, Personnel, Operations, Inteliigence, 
Logistics, Plans and Operations. 

jhe Adr Force Headquarters has the responsibility 
for organization, training and equipping the ROK Air Force 
for the conduct of sustained combat operations. In national 
Security the position of the ROK Air Force is critical 
because the Communist North Korean Air Bases are located 
memy close to the capital city of Korea. North Korea is 
S@pericor in numbers of aircraft, and stands face to face 
fememe KOrea along the 155 mile Demilitarized Zone (DMZ). 
pmether consideration is that the North Korean aircrafts are 
mie to reach the capital city of the ROK within 3 or 4 
immrces Of crossing the DMZ line. 

in Ondenretomstrengthen the war potential of the 
Korean Air Force, it is imperative that personnel management 
for a small number of elite members under limited resources 
Mempertormed very efficiently. The ROK government spends a 
mmener large percentage of the total military budget for 
national defense, and the Department of National Defense 


spends a significant portion of the national defense 
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expenditure for personnel. The largest investment is in the 
Pereesic Force. In order to reduce the national defense 
expenditures and increase combat capabilities, the Air Force 
needs a computerized management information system for 


personnel management. 


Wee aspects, Of CAC and Air Force Headquarters Personnel 
Management 


Personnel managers need data about a specified 
individual's qualifications and a given unit's Average Level 
meme roLiciency (ALP) in order to analyze, investigate, and 
Mame tor their organizations. Information about a specified 
Miaividual's qualifications can be derived from functions 
involving procurement, education and training, assignment, 
treatment, promotion and retirement. Information about a 
Umit's ALP can be derived from the collection of the individual 
memsonne! power data. It is important to increase individual 
@goemeroup proficiency in the personnel management field in 
mmeter that the right people move into the right jobs at the 
meee Cimes and under the right circumstances. A specified 
imdividual's qualification becomes the basis for a given unit's 
ALP. Each factor of the individual's personnel management 
will be discussed based on Reference 9 and Reference 10. 
fe Personnel Administration 
a oever sonnel Procurement 
Penmoonne mM DEOCIGeMeNialSesthe process of .aining 


manpower for filling vacant positions which cannot be filled 


ay 





BMaon wilehin the Organization itself. Erficient personnel 
MmecuLement requires information concerning the candidates 
Bia t have been selected. Their relevant data must be kept 
and maintained so that they can be used at any time for 
transfer, new assignment, promotions, etc. 

b. Personnel Education and Training 

Information regarding the education and training 
Bempersonnel 1S used mainly for personnel development and 
promotion.. This information is used to match or minimize 
the difference between skills required to fill a position. A 
Benson's Educational background can be used to gain special 
miowLedage needed to place a person in a particular job and 
Bomprepare that person for a new assignment. Further, this 
mieormation can be used to plan and monitor the careers of 
leaders, or those personnel with special abilities who will 
be future leaders, in order to extend their abilities and 
Bert is in preparation for future positions. 

The results of personnel development can be 
measured by observing the performance of individuals in 
Memmang necessary skills and abilities. This information 
can be recorded in the personnel database and used as a 
isis for further career development. 

Gemeensonume. ASSLonment 

Personnel assignment deals with selecting the 

right officers for the right positions. Three aspects must 


be considered for this job. 





mueevery Vdeane position must be filled by a person with 
Piceadbpmrlty =O Carry Out the job in the best manner. 
2 The capabilities and skills of each person must be 
fitted to the job so that he satisfies the job area. 
wee each person who 1s selected for a new position must 
have finished compulsory education and training 
courses, and must have carried out compulsory position 
in each rank. 
i cEsoonne lh. 1 reatnent 
Personnel treatment deals with the physical and 
psychological aspects of person and job. These include such 
areas as mental and physical health, recreation, rewards, 
Memsonnel service, transportation, salary, retirement plans, 
Military insurance, annual pension and vacation (periodic, 
sick, reward, emergency). Mental and physical health 
conditions and rewards affect promotion and new assignment. 
Babary, military insurance, annual pension and personnel 
service affect the life of the family. Recreation, rewards, 
personnel service, transportation, retirement plans and 
Meat lons are very important for military morale. 
Cewee ce hscoume! Promotion 
The promotion policy is that personnel who have 
finished minimum service duration in a rank and possess the 
Capability to perform in upper level positions, be 
considered by a promotion selection committee. Therefore, 


the necessary information should be prepared and provided to 
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the decision makers, namely the promotion selection 
committee. The list of personnel who can be promoted should 
be provided according to rank and branch of service. The 
promotion DmiomEamles Oueal pensonnel should be provided 
mamincorporating several items into these tables. These 
items are as follows: 

mu ine Career which is required on current rank. 

@. the result of efficiency reports which are taken 

amualily on Current rank. 

fee Military education. 

4. Rewards and punishment. 

meee Pnysical and mental health condition, etc. 
ie promotion selection committee selects the officers to be 
meomoted each year from officers who are recommended for 
promotion according to the above information. The necessary 
mmoer Of Officers to be promoted each year are decided upon 
meecne end of the previous year. 

Mr Personne! oepanat lon 
Lewsonme! “Separation Occurs when personnel 

voluntarily ask to be retired from the Air Force through the 
process of retirement or when someone cannot work or 
mereinuec in the Air Force because of problems with their 
Membal Or physical health. Personnel who request retirement 
mest have worked for the minimum public service duration in 
B@ennir Force. The minimum public service durations are 


@epterent between resource organizations. If certain 





midividuals have attended a special service school, they 
must complete the additional term of obligation required for 
that school. However, if personnel reach the age limitation, 
fank limitation or maximum public service duration, they 
must retire on that day. Therefore, retirement information 
should be prepared and provided to decision makers (i.e., 
retirement selection committee). This information will 
maelude public service duration, a list of officers who wish 
to retire and have satisfied the minimum requirements, and 
feist Of officers who can no longer work in the Air Force. 
feeeuser Required Intormation for Personnel Management 
The main functions of personnel management tor the 
ROK Air Force have been described. Next, the information 
needed to analyze, investigate, plan, and apply those 
functions is described. Information which personnel 
managers may request might include: 
meee List Of all new officers for each source organization 
including attributes such as academic ability, 
classification of home town, next of kin, health 
Sond tion, completion rate of education and training, 
Sec. 


The number of cadets or candidates who should be 
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inducted in the next year or at a specified year for 
each source organization. 
Sel ist allocation of ali officers by rank and by 


military education and training course. 
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Do suimcny MOtmaneOrmrcer's Career from a certain 
Dac oucsanikempmto the Gurrent rank. 

S. Total of classified flying time of all combat crews 
based on rank, qualified grade, capability grade, 
month and annual period, and organizational unit. 

oeelist of all retired combat crew, who can be recalled 
in the event of a national emergency, based on age and 
new occupation. | 

7. Present an information list for promotion purposes for 
each rank and branch, including career, result of | 
CrLtlGiency record, education, rewards and punishments, 
nealth condition, and the order of promotion 
recommendation. 

feeeeresent all information which 1s required for 
micgmviduial piles quality control (I1PQC). 

All queries which may be made by personnel managers 
Cannot be foreseen because different managers request 
different information. Personnal managers might need other 


mieormation for their job in addition to that described above. 


B. DATABASE DESIGN 
ime Introduction 
Database design is one of the most important steps 
in the development of a computerized information system. 
Size and complexity combine to make this task 


disproportionately time consuming and expensive. 





Developing a database is an evolutionary process 
with the objective being an "idealized database." This is 
information that contains all the necessary data about all 
feeets Of an Organization's operations and from which can be 
Berpracted instantaneously, in any form desired, information 
in response to inquiries in any format. 

There are many ways in which a database can be 
@esigned. Generally, Heese design consists of two 
separate components: logical design and physical design. 

We will consider only a logical design technique for a 
relational database model. 
2. Structure of a Relational Database Model 
a. Relations 

The data structuring tool used by the relational 
database model is a relation which is simply a two- 
memensiOnal tabie. Figure 3.1 illustrates a relation called 
PERSON, of degree 4. The four domains contain set values 
mepresenting, respectively, RANK, Service Number (SN), 


Military Occupation Specialty (MOS), and NAME. 


PERSON 






ase 
Cee af 
Captain Park, Ki Soo 










pueine 5. ] ssAnwExamplie of A Relation 


OS 





Mice wikeaomdin, tor e€xample, 1S the set of all 
valid ranks. Note that there may be ranks included in this 
@emain that do not actually appear in the PERSON relation at 
mmmse particular time. As the figure illustrates, it is 
convenient to represent a relation as a table. Each row of 
mfiemtable represents one n-tuble of the relation. The 
number of tuples in the PERSON relation is three. 

b. Domains and Attributes 

A domain is the set of possible values that an 
meerabute can have. That is, "Cha, Sang Ho'' is a value of 
attribute NAME. An attribute is the property of an entity 
which assocaites a value from a domain with each entity. 
For example, the relation PERSON is defined with four 
attributes (RANK, SN, MOS, NAME), and each attribute is 
drawn from a corresponding domain. 

c. Keys 

A key can be considered an attribute or a set 
Of attributes which uniquely identify each entity in an 
Sueecy Set. For example, attribute SN of the PERSON 
relation has the property that each PERSON tuple contains a 
Gistinct SN value, and this value may be used to distinguish 
meme ctuole from all others in the relation. SN is said to 
Bemtne primary key for PERSON. 

3. Schema Design 
A relational database is specified by a relational 


schema which consists of one or more relational subschemas. 
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A relational subschema is a listing of a relation name and 
mesecoOrrespomding attributes. Figure 3.2 represents an 
example of a relational schema for ROK Air Force's 


personnel management. 





PERSON (RANK, SN, MOS, NAMB) 
EDUCATION (SN, RANK AT THAT TIME, SCHOOL NAME, 
COUNTRY, LOCATION, PERIOD, MAJOR, RESULT GRADE) 


Preure S.2 An Example of a Relational Schema 


tierce dane  FOlr stems reguired In Order to design a 
relation schema:[Ref. 11] 

1. Determine the information requirements for the 
@ttrerent areas of the organization involved in the 
schema design. 

2. Express the information requirements as an enterprise 
gescription. 

3. Obtain a database description which more rigorously 
defines the database structures and constraints, and 
Satisfies the information requirements. 

4. Check the schema for performance requirements of the 
BEOSpecCtive users. 

The data are modeled initially and administered 
thereafter by people in certain roles.[Ref. 12] Those people 


Can be classified as follows:{Ref. 13] 





1. The enterprise administrator specifies the enterprise 
description -(conceptual schema). 

2. The database administrator is concerned with specifying 
the physical aspects of the database description 
(internal schema). 


The application administrators provide the multiple 
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views (external schemas) for the various application 
areas within an organization. 

Each administrator is responsible for providing a 
Mmeerrcular view of the necessary data, the relevant 
relationships among the data, and the rules and mappings 
between views. Each administrator role uses tolls and 
techniques dseorovigedebyeaaGata models for the successful 
description and operation of the database. 

a. Requirements Analysis 

Wne first step of schema design 1s requirements 
analysis. This step consists of a high-level analysis of 
Meee runction of an organization. The functions of the 
departments of personnel management given in the previous 
part of this chapter are an example of requirements analysis. 
mmespurpose of this step is to: 
meeeGain tamaiiarity with the area of the organization to 
be modeled. 
Z. Determine the information requirements of the 
organization without regard to constraints other than 


the way in which the organization does business. 





3. Represent these requirements via some formal modeling 
technique. 

Tiemiietn) Ppimpese Otmerequirements analysis is to 
understand the user's needs. Subsequent steps of the schema 
design process can transform these needs to subschemas 
according to the relational data model. 

In order to meet the requirements, there are two 
views: How the organization werares and what 1S required to 
Support the operation. The how and what are aspects of an 
G@ieeanization which can be represented in terms of the 
memetions of the organization and the data classes that 
Sueport these functions. 

(1) Function Classes. A function in an 
organization is an essential activity or decision required 
Bemmanage the resources and operations of the organization. 
Pum@etiOns 1N an organization are identified by: 

1. Examining statements of purpose of a task or an 
organizational area. 
2. Examining work programs in an organizational area. 
fee identifying products or services provided by an 
organizational area and determining what functions are 
needed to produce such products and services. 
Following the above principles, we have 
defined the functions of the Department of the ROK Air Force 
Personnel Management. The functions for Headquarters are 


procurement, education and training, assignment, treatment, 
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Pmomotlon, and separation policies. In particular, the 
functions for CAC are assignment, education and training, 
ma IPQC policies for combat crews only. 

(2) Data Classes. Before discussing data 
classes, we extract specific data groupings from the present 
jc system in different functional areas. These files, 
memevant to each person, consist of data elements which are 
required by different users “ee different functional areas. 
M@mese files are: Person, Military Training, Salary, Medical 
meords, Inspector, and Supply Record. Furthermore, these 
files are independent of one another, therefore, all data are 
not shared by all organization areas. 

A trend toward integrated file structures 
has resulted in the grouping of all data elements relevant 
to the management and operations section of a user 
G@reanization. The emerging database concept requires placing 
meierelevant data in one database in a consistent and 
Seanaardized manner, eliminating unnecessary duplication and 
Mmereeiandling, and providing selective inquiry and extraction 
maori iiies designed to meet a wide variety of information 
memuests. Therefore, data classes must be well organized 
mimordaer to achieve the goals of this system. 

A data class in an organization is an 
aggregation of data (attributes) that is required by a 
MmMecioOn Or is produced by it. Data classes in an 


Organization are identified by examining the data required 
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or produced by a function. The functions and corresponding 
data classes for personnel management are shown in 
proure 3.5. 

(mldeamoletionanmy.= ine generation of the data 
Mrmetionary which documents functions, data classes, and 
their interrelationship should be initiated at this 
pomnt.[Ref. 14] 

Individual DBMS have their own methods for 
defining data descriptions. Each has a repository for the 
data base description, a language facility to process that 
description, and a mechanism to input that description to the 
mai. A comprehensive dictionary will include cross- 
reference information such as which programs use which 
pieces of data, which departments require which reports, and 
so on. The general objectives of a data dictionary are to 
meovide:[Ref. 15] 

ime various reporting facilities such as cross-reference 
PepObes, Chances e€frecting reports, error-reports, etc. 

2. Various retrieval capabilities such as keywording, 
indexing, and online or batch querying. 

3. Common language to control, retrieve and update the 
data dictionary. 

4. Validation and redundancy-checking capabilities. 

5. security safeguards to control access to the data 
dictionary. 


6. Data description generation. 
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Function Pune: ton 


Procurement Promotion 


Education and Training Separate 1on 
Assignment Treatment 





FUNCTION 
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pweautH conpition || ft 
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Parner owe 
| compat trarnine/quatty || = | || 
REQUIRED SERVICE 
| Prowotzon ist | tt tt 

a ee 


TEMPORARY DUTY 


PERSONNEL SUPPLY 


sa CCE 
VACATION CETTE 


Figure 3.3 Functions and Data Classes 
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Miewcata Gducttonary contains all the 
mils@rmation from logical data description to the detailed 
paysical data description. For instance, Figure 3.4 shows 
the schema of the relation PERSON as it might appear in a 
data dictionary. 

Sepeeiieerprise  Nesech il pci1on 

Enterprise description consists of five phases. 
evemiirst phase 1s identifying ali the entities of interest 
Bomeach Organizational area, the relationships between then, 
eiaeany constraints which may exist. The first phase 
results in a view of the schema for each organizational area. 
miese Views are then integrated to form an enterprise 
description which describes the entire conceptual schema. 
This description is used mainly for communication between the 
users and the schema designers. For each entity type 
identified, a description of the entity type is produced and 
mmemessociated data classes identified. The description 
Mames the entity type, defines what it represents, and lists 
mesmassociated attributes. Entity type identification is an 
iterative process. The description of an entity type may 
Gmamec many times before everyone agrees that it is right. 
ivescntity types identified for personnel management are 
shown in Appendix A Part III. 

In the second phase, the relationship between 
entities are identified from the functions. In order to do 
this, there are several considerations to be taken into 


fecount : 
4] 








PERSON (RANK, SN, MOS, NAME) 


RANK mepmesent rank=or the officer 

ON ; service number 

MOS : number of military occupational specialty 
Name milaney OL thouOrrlLcer 





Figure 3.4 An Example of PERSON Schema Data Dictionary Entry 


1. For each function, what are the known correspondences 
Between EMtlty types associated with the function? 
2. What is the appropriate name for each relationship 
ype? 
See What is the meaning of each relationship iwc ce leien 
formally or inrormally? 
4. What combinations of relationship types make sense as 
separate, identifiable relationship types? 
The relationship among entity sets is simple an 
Mcered list of entity sets. <A particular entity set may 
@epear more than once on the list. The relationship types 


meeained from this process are shown in Figure 3.5. 


PROMOTION -- function 
PERSON EFFICIENCY -- between PERSON and EFFICIENCY REPORT 
PERSON CAREER -- between PERSON and MILITARY CAREER 


Figure 3.5 An Example of Relationship Types 


The next phase 1s te complete the enterprise 
description step, by identifying constraints on the 


@eeributes, entity types, and relationship types. It seems 
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Better to state all constraints explicitly rather than as 
inherent constraints. To help identify constraints, the 
following questions are posed: 
ime What is the domain of values for each attribute? 
2. What are the known functional dependencies between 
attributes of each entity type? 
S. What are the keys for each entity type? 
4. What is the mapping property of each relationship? 
5. What are the predicate constraints to be placed upon 
the data? 
mamctional dependencies will be discussed in detail in the 
femme Section. 

Seeromiinikeulke CO arrive at a nee CPeGonstraints 
that represents the application and its consistent and 
feasible, because some forms of the constraints are difficult 
to understand and are prone to misunderstandings and errors. 
The result of this phase of the enterprise description step 
is a list of the entity types and their attributes. The 
results of this step are also identified in Appendix A Parts 
imand IIT. 

The fourth phase of the enterprise description 
step integrates views for each organizational area into one 
Pueerprise description. The enterprise description is a 
synthesis of the information requirements of each 
Grganizational area. Documentation of the enterprise 


description consists of summarizing the data obtained from 
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the interviews in a suitable manner. [It also includes 
retention of the universe of discourse on who uses each 
mimedty type and relationship type. It may be necessary to 
iterate by negotiating with each organizational area until 
mee, Organizational areas agree that the enterprise 
Meecription accurately reflects their information 
meguirements. 
The final phase of the enterprise description 

Seep identifies the transaction-processing requirements of 
meemOoregalization with respect to the enterprise description. 
mee current and projected transactions are included. For 
eee transaction, the designer identifies its nature 
Meetricval, update, delete, insert), its frequency, its 
origin (organizational area), and its purpose, together with 
the point(s) of the schema it affects. The previous four 
meeps are used as a basis for describing the transactions. 
jmeneip identify requirements for supporting transactions, 
the following questions are posed: 

meeewiat transactions are required by each organizational 

area? 
Smvndt entity types, attributes, and relationship types 


are involyed in each transaction? 


GA 


What is a sketchy outline of each transaction in terms 
Seeene emterprise description in English or a problem 
specification language? 


a What kind of access is required by each transaction? 


44 





S$. What is the mode of operation of each transaction? 
6. What is the frequency of each transaction? 
7. What is the processing priority of each transaction? 
8. What is the need for concurrent update activity? 
9. What kind of pattern of database usage do we expect? 
me What reports are needed? 
mee What 1s the format of each report? 
12. What is the acceptable time frame for producing each 
Rema it. 
meee Wnat security requirements are important? 

(imiemGestit Or this step 1S a list of all 
Mmemoactions and their characteristics. Figure 3.6 contains 
a simple example of transactions required for personnel 
management. The list of transactions is shown to the 
different organizational areas and an agreement on a final 
meet 1s reached together with some priorities for 
mueementation. Ihe overall results of this final step are 
@enmctcained in Appendix A Part IV. 

c. Database Description 

This step transforms the enterprise description 
into a database description which means a description of the 
proposed schema according to the data model in the target 
DBMS. We will illustrate the process for the relational 
approach. 

Poumameue lit loOmate Deion, the enterprise 


description is transformed into a relational schema 
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Meeune 5./). Entities are mapped into base relations which 
are permanently stored in the database. Relationship types 

are mapped into base relations if they are information bearing. 
Non-information-bearing relationship types can be mapped into 


derived relations (1.e., joins). 


Transaction: List of all officers who have excellent 
ability in the German’ language, hold the rank of 
Captain, whose MOS is 2214, have a Master's degree 
and whom have graduated from the Air Force Academy. 

Entity: PERSON, FOREIGN LANGUAGE PROFICIENCY (FLP), 
EDUCATION 

Relationship types: PERSON FLP, PERSON EDUCATION 

1. Retrieve PERSON entity (for RANK, MOS, COMMISSION 


Hater fey) 

@. Retrieve all PERSON entities related to the FLP 
VelamamrEKoON FILP , 

3. Retrieve all PERSON entities related to the 
EDUCATION via PERSON EDUCATION. 


Figure 3.6 A Simple Example of Transaction 


The result of transforming the enterprise 
description into a database description represents a 
documentation of the schema. In addition, we have a sketch 
@f cach transaction to be performed. The schemas and 
transaction sketches should again be discussed with the 
different organizational areas in order to obtain each 


Organization's approval. 
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PERSON (SN, RANK, NAME, RRN, MOS, PERMANENT ADDRESS 
PRESENT ADDRESS, COMMISSION TYPE, COMMISSION 
DATE, BRANCH OF SERVICE, MARITAL STATUS, 


RELIGION) 
key: SN 
ELP (np BE ORSEANGUAGE,S PROFICIENCY DEGREE) 
key: SN 


ASSIGNMENT POLICY (UNIT NAME, RANK, REQUIRED DUTY, 
HMOs PREREQUISTTESPOSITION, PREREQUISITE 
EDUCATION) 

key: UNIT NAME 


PEOUIRED SERVICE (SN, FINAL YEAR OF TOTAL REQUIRED 
SERVICE DURATION, MAXIMUM AGE FOR REQUIRED 
SERVICE AT THAT RANK, MAXIMUM DURATION AT THAT 
RANK, FINAL YEAR OF MAXIMUM DURATION AT THAT 


RANK) 
key: SN 


BemoON PLP (SN, RANK, NAME, TYPE OF LANGUAGE) 
key: SN 


Poo LGNMENT POLICY REQUIRED SERVICE (UNIT NAME, RANK, 
Pinte .EAR OP TOTAL REQUIRED SERVICE DURATION) 


key: UNIT NAME 


Figure 3.7 A Relational Schema for Procurement Policy 


4. Schema Analysis 


The major direction of the design effort is to 


obtain an accurate schema, that is a schema representing the 


47 





database application on which the transactions of the 
mapecation can be serviced. Given an abstract schema, what 
are the desired properties it should have and how does one 
transform the schema into another equivalent schema with the 
desired properties? 

Basically, a schema consists of structure and 
constraints. Constraints can be used as a guideline for 
deciding the schema's structure according to three criteria: 
mepresentation, nonredundancy, and separation. Representation 
Should be a guideline for getting a good schema. Non- 
redundency states that a constraint that can be derived from 
Pree structures and other constraints already specified ina 
schema, should not be redundantly specified. Separation 
requires that we structure the schema in such a way that 
information units, as represented by constraints, are 
separated. 

Constraints can be used as a yardstick to evaluate 
and manipulate schemas. The most well understood and simple 
type of constraint deals with dependencies between 
meeributes in a schema. 

There is a tremendous amount of choice in schema 
design regarding structuring of the data and the 
specification of constraints. Many different schemas can be 
associated with the same application. It would be nice to 
Selmlesup With one that is “good" and "right." "Good" usually 


means a schema that provides reasonable database 
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Mertormance. Database performance is a function of physical 
database design, Diet tsis NOt covered in this thesis. 
eepeht’ usually means that the schema reflects the real 
Mmaeopertiecs of the world the designers are trying to 
represent. This latter point is discussed in the following 
meecion. 

aeeecunet ional Dependencies 

The functional notion of functional dependence 
(ED) can be defined as: Given a relation R, attribute Y of 
Peers functionally dependent on attribute X of R if and only 
if each X-value in R has associated with it precisely one Y- 
value in R (at any one time). That is, if f: X —->Y, then 
iets) said to be functionally dependent on X, and X 1s said 
meomrunctionally determine Y. When there is only one 
functional dependency f from X to Y, the notion X — Y is 
used as an abbreviation. 

In the Person-and-Family database, for example, 
attribute RANK, NAME, and MOS of relation PERSON are each 
functionally dependent on attribute SN, because, given a 
Meecacular value for SN, there exist precisely one 
corresponding value for each of RANK, NAME, and MOS. 

ihemOmlcun Ey pewOr Tl can be detimed as: Given a 
iemeaciOn R, attribute Y of R is functionally dependent on 
attribute X of R if and only if, whenever two tuples of R 
agree on this X-value, they also agree on their Y-value. 


fomecxample, relation PERSON in Figure 3.8 satisfies the FD 
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RANK —> MOS. Furthermore, the attribute BASIC SALARY of 
memation SALARY is functionally dependent on the composite 


attribute (RANK, SALARY STEP). 


—— ES Eee 


11330 SiNeeaeo leak: 


siz0 | chung, Ko Ja | in21 


SALARY 


RANK SALARY STEP [BASIC SALARY | F-ALLOWANCE 


a 


Gaptain [sia an 2000 





FAMILY 


SN SPOUSE NAME SPOUSE RRN- NO OF DEPENDENT 


[2220 | Park, Min Ok | 12111-24561 — 


S110 Shin, Mun So 13241-45326 3 





Paeure 3.8 The Person-and-Family Database: Relational View 


We represent the FDs in an example set of 
relations by means of a functional dependency diagram. An 


Eeample 1S shown in Figure 3.9. 
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RANK | Silber | Syleye | 


J. J 

ex |< > Ned BASIC SALARY | 
ne | 

| FAMILY ALLOWANCE | 


NJ 


| RANK | 


SN | ——> | SPOUSE NAME - 
— a 


ea 


| SPOUSE RRN | a NUMBER OF DEPENDENT 


| RANK | 
| SALARY STEP | 






——— BASIC SALARY | 


Meure 3.9 Functional Dependencies in Relation PERSON, 


FAMILY, and SALARY 
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b. Multivalued Dependencies 
Multivalued dependencies (MVDs) are a 

generalization of functional dependencies. The idea of 
functional dependency is limited in the following sense. 
When A multidetermines B (A ——>B), A not only determines 
By but it determines B uniquely. The uniqueness limitations 
fan be too restrictive in some cases. Consider, for 
instance, the following example of a relation shown in 
mreure 3.10. 


ASSIGNMENT POLICY 


UNIT NAME RANK 


1100 CAG TAIN ibaa ta 


POO MAJOR 1120 
112.0 CAPTAIN bez 


COLONEL eZ 





Figure 3.10 An Example of Multivalued Dependency 


In this example, there is a multivalued 
dependency from UNIT NAME to RANK written UNIT NAME —--— 
RANK. The multivalued dependency says that all RANKs depend 
on the UNIT NAME and not on the individual MOSs. 

Functional and multivalued dependencies can be 
sea to specify particular types of constraints on entity 
types. These constraints relate to properties of the 


mappings between the attributes of an entity type. These 
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properties are specified during schema design and can be 
used in the analysis of a schema to eliminate undesirable 
mueoperties. 


c. Decomposition of Relation Schemes 


The decomposition of a relation scheme R = (Aj > 
Ans see, AW) 1s its replacement by a collection p = (Ry > 
Ro » a, RD of subsets of R such that R = Ry LJ R, 2 ee Ra: 


There is no requirement that the Ri 's ber disjoint . 

Some peculiar conditions arise when we lump 
attributes together which should be kept apart. These 
conditions are called anomalies. We will illustrate these 


anomalies using the following relation scheme. 
COMPANY (Employee#, Department#, Manager, Contract Type) 


The following anomalies may arise in 
Manipulating this relation. 

1. Update anomaly. The change of a manager in a 
department necessitates a series of changes of this 
manager for each employee and contract type in which 
the department is involved. That is, a change must 
ripple through and cause a series of changes for the 
tatabase to be consistent. 

2. Insertion anomaly. When the first employee is hired 
for a department, a manager and contract type must be 


specified. 


ors 





3. Deletion anomaly. When the last employee is fired, 
ay deparumlent Mimeermation will cease to exast. This 
can be considered an anomaly if we want to retain 
important, long-ranging information about the 
department. 

meerecdun@ancy. The contract type and the manager of a 
department are repeated in many tuples. The above 
Situation can be avoided by decomposition. 

In the above example, the anomalies can be 
eeeninated by breaking the relation scheme into two 


relational schemes. 


Employee (Employee#, Department? ) 


Department (Department#, Manager, Contract Type) 


In the decomposed schema, employees and 
departments are isolated and related only by specifying the 
department in which an employee works. Decomposition is 
based on the two functional dependencies Department# —> 
Manager, Contract Type and Employee# —> Department. The 
decomposition isolates these two dependencies in separate 
memacion Schemes. As a result, they do not interfere with 
Seremeother. These side effects are eliminated by isolating 
the dependencies in different relation schemes. 

MECcCeOMPOSMemoneiS Considered "good" when the 
Seiema 6 1s E€quivalent to R and when it eliminates some of 
the anomalies. For the two schemas R and p to be 
equivalent, the following two properties are necessary: 
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PaelecstecsSe Cine lore formally, the join of relations 
Ry and R, is lossless if Ry 1 Ro —_—> Ry or R, U R, —> R>- 
Mlsoeeite can De aoplted to multivalued dependencies. 

2. Dependency preservation. A decomposition is 
dependency preserving if its dependencies are preserved 
within the new relation schema. 

d. Normal Forms for Relation Senencs 

MOnidlizaeron eneery 1s bumlt around the concept 
of normal forms. A relation is said to be in a particular 
memmat form if it satisfies a certain specified set of 
@elstraintsS. For example, a relation 1s said to be in first 
mormal form if and only if it satisfies the constraint that 
memecOntains atomic values only. Codd originally defined 
first, second, and third normal forms in Reference 7. That 
is, all normalized relations are in INF; some 1NF relations 
are also in 2NF; and some 2NF relations are also in 3NF. The 
motivation behind the definitions is that 2NF is "more 
desirable" than INF, in a sense to be explained, and 
Similarly 3NF is more desirable than 2NF. 

We have chosen 3NF relations in designing the 
database described in the previous section, rather than 2NF 
‘or 1NF relations or other more intricate normal forms (4NF, 
for example) which are very difficult to implement. We 
will discuss oniy INF, 2NF, and 3NF here. The way that a 
relation scheme is turned into a normal form relation scheme 


waoy decomposition. 
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Penetatnenwas inetarst normal form 1£ every 
Maer ibuce 15 a Simple attribute. That is, there are no 
@emposite attributes. For instance, consider the relation 


scheme. 


SALARY (RANK, SALARY STEP, BASIC SALARY, ALLOWANCE 


(FAMILY, MOS), TAX) 


mew attribute allowance is obviously composite. We can 
eliminate this by constructing a new relation scheme as 


follows: 


SALARY (RANK, SALARY STEP, BASIC SALARY, FAMILY 


ALLOWANCE, MOS ALLOWANCE, TAX) 


This example suggests a general algorithm for putting a 
relation scheme into INF. We just expand the relation 
scheme by eliminating all composite attributes and replacing 
fg@emewith their constituent parts. 

POlmcwiouDaretcilare relation the key 1s RANK, 
SALARY STEP. However, a SALARY relation that is already in 
INF 1S said to be in 2NF since it has no partial 
dependencies of nonprime attributes on keys. If a partial 
dependency exists, it will result in update, insertion and 
deletion anomalies. 

A relation is third normal if it is in 2NF and 
it has no transitive dependencies of nonprime attributes on 


meys. in Figure 3.11 SALARY] is in 2NF but has the 
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transitive dependency RANK, SALARY STEP —> BASIC SALARY -—> 
TAX, where TAX —4—> RANK, SALARY STEP and BASIC SALARY ——> 
RANK, SALARY STEP. This transitive dependency results in 
update, insertion, and deletion anomalies for values of the 
tax attribute as well as redundency of tax values. To get 
Pia Of this transitive dependency, the relation SALARY] can 
be decomposed into two relation schemes and extensions shown 


mir ioure 3.12. 


SALARY1 
RANK SNEAKY STEP BASTC SALARY TAX 
WO 9 1000 90 
WO 10 1050 95 
Captain 4 1050 95 
Major i 1200 100 


RANK, SALARY STEP —> BASIC SALARY 


BASIC SALARY ~—> TAX 


EFueinie 5.11 Example Relation in INF and ZNF 


A relation is in 3NF if and only if, for all 
mimes cach tuple of R consists of a primary key value that 


identifies some entity, together with a set of mutually 
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independent attribute values that describe that entity in 


some way. 


SNE. 


SALARY 2 


RANK SALAR TP olEP 


ae 


Major 1 





TAXATION 






BASIC SALARY 
ee ae 


1000 


1050 


LAI 





Figure 3.12 


See iMePLEMENTATION OF A PROTOTYPE 
im introduction 

The ORACLE relational datavase 

a computer program that manages pieces 

in a computer. ORACLE offers the ease 

and flexibility of a modern relational 


compromising system performance. 
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imsparticular, Appendix A Part III is based on 


BASIC SALARY 


1000 
1050 
1000 


EI) Sy0. 


1200 


TAX 






Example Relations in 3NF 


DATABASE USING ORACLE 


management system 1S 


of information stored 
of use, functionality, 


DBMS without 


White users percelve their 





data as tables, ORACLE employs sophisticated data storage and 
access techniques to optimize system performance. Today, 
ORACLE is He UNE MESA in large production applications and 
online transactions involving databases with billions of 
Characters of data. 

SPAGie useswene Sl (Structured Query Language) data 
language. SQL is a query language, a data manipulation 
Maneuage, a data definition language, and a data control 
Mameuage. With conventional systems, we have to learn a 
[meererent language for each one of those functions. All SQL 
facilities can be used directly from a terminal or embedded 
in programming languages such as COBOL, FORTRAN, BASIC, and 
PLI. <All users - regardless of who they are or what they 
are doing - use the same language, SQL. 

Limeils sceueron. we Will @aimplement the data 
Manipulation aspects of ORACLE. In particular, we present 
memo ML portions of the SQL language. The SQL DML operates 
on both base tables and views. All examples will be based 
on the PERSON-and-SALARY database of Appendix A Part III. 
immemresults of examples of the selected operation are 
Bepended to Appendix B Part I. 

mee DOE Description 
a. Tuple Relational Calculus 
ane coneept or a relational calculus 
eeecitically tailored to a relational database was first 


peeposed by Codd.[{Ref. 8] There aré the two forms of 
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mieronabecaleulus, called tuple relational calculus and 
domain relational calculus. weeupme calculus €xpression 1S 
essentially a nonprocedural definition of some relation in 
terms of some given set of relations. Formally, the 
expressions of the tuple calculus are from the following 
Parements : 

meeeachn ttiple varzable is constrained to range over some 
Mamed relation. if tuple variable T represents tuple 
Mmnmencitnewexpression TsA represents the A-component 
Seetnewhene AwtS an attribute Of the relation over 
wereh T ranges. 

Peeeenditions Of the form X * Y, where * is any one of =, 
/=, , =, , Or =, and at least one of X and Y is an 
expression of the form T.A and the other is either a 
Similar expression or a constant. 

b. Basic SQL Commands 


(1) Memes Cineedeeiable wee Wesecreatesa table using 
the CREATE TABLE command: 


CREATE TABLE PERSON (SN number(6), RANK char(10)}, NAME 
mart !0), BIRTHDATE char(10), MOS number(4), CD char(10), 


CT number(3), MS number (3)) 


(elicciomemoata Into a mtable. Immediately 


after a table is created, rows can be entered into the table 
using the insert command. The following command was used to 


enter the first row into the PERSON table. 
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ot we Omer rRoeONeVALUES (ITIL, ‘MAJOR! ,'CHA, S. H.', 


'O8-MAR-42', 1111, '10-MAR-70', 1, 1) 


In the insert command we name the table(PERSON) into which 
the row is to be inserted and list data values that go into 
each column. 
OC) eerie oUbecommands. There are other SQL 
commands for other functions: 
1. SELECT - This command has at least two part: a) The 
SDebeerecilause F1sSts the column we want to retrieve. 
b) The FROM clause names the tables from which to 
Geerieve the columns. 
2. DELETE - Remove a row from a table. 
Pee UPrDAITE - Modify a field in a row. 
emitted) ODeTaAt tons 
ice iuindancemeal Operation in SQL 1s the mapping, 
represented syntactically as a SELECT-FROM-WHERE block. A 
WHERE clause causes a "search" to be made, and only tuples 
meatemeet Che search condition are retrieved. A WHERE 
clause search condition can use any of the following 
memparisOn operators; =, '=, , =, , and =. 
For example, the query "Get officer's RANK and 


NAME whose MOS is 1111," may be expressed as follows: 


SELECT RANK, NAME 
FROM PERSON 
WHERE MOS = 1111 
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RESULT 


Gorone! Kersie D. J. 





From this example we can see that the "mapping" operation 
is effectively a horizontal subsetting followed by a 
vertical subsetting. Results of a wide variety of retrieval 
@ueries are displayed in Appendix B Part II. 
d. Group Functions Operations 
In all the examples so far, we have selected 
values stored in each row of a table or values calculated 
for each row. That is, we have selected information about 
individual rows stored in database. We can also select 
"summary'' information about groups of rows in the database. 
ORACLE provides five group-functions that can be 

meeered to data retrieved in a query: 

maeAVG - Complete the average value 

2. SUM - Computes the total value 

See MIN - Finds the minimum value 

4. MAX - Finds the maximum value 

5. Count - Counts the number of values 

Be Data Security 
ORACLE allows users to share access to the same 

database. While users can share data if desired, ORACLE 
will automatically keep data private unless a user 


explicitly gives another user access to it. 
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ORACLE requires users are to provide user USERID and 
PASSWORD when logging on. 

Sharing Gata with other users. When a user creates 

a table, the user become the owner of that table. Only 
PiewOwner Cadi use the table uniess he wants to share 

mar wiehn Other ORACLE users. Users can give and take 


away access to their tables with the SQL command: 


GRANT - give other users access to user's tables. 


REVOKE - take away other users access to user's tables. 
The GRANT command is made up of three basic clauses: 


GRANT - a function (SELECT, INSERT, UPDATE, ALTER, INDEX, 
CLUSTER) 
ON - a table or view 


TO - a user 


nemeexamole: “Haye user CHA grant the SELECT privilege 


on the PERSON table to a user named KIM. 


GRANT Sy oy bel Ot 
ON PERSON 


TO KIM 


Once a privilege has been granted it may be withdrawn 
by means of the REVOKE command. Privileges are 
revoked from the named grantee and from all users to 
WHOimenomNass CLanwca them. For example: Revoke from 
Viieica@. wile cOonlNceRT Into the PERSON table. 
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REVOKE INSERT 
ON PER OUN 


FROM KIM 


3. The database administrator. When the ORACLE database 
is first created, there is only one user authorized to 
log on. That user has the name SYSTEM and a password 
MANAGER. If a user logs on under the name SYSTEM, he 
has full DBA authority and can create other users. 
Example: Create a new user named CHA with DBA 


authority. 


CONNECT SYSTEM/MANAGER 
Rant eDBA TO KIM IDENTIFIED BY CHA 
Example: Log on as KIM 


CONNECT KIM/CHA 


4. Changing user password. A user with DBA authority 
(like KIM or SYSTEM) can change another user's 
password. For example, user could change the password 
of SYSTEM to something other than MANAGER. This will 
MmeventeOtner Users logging On with the user name 
SYSTEM and gaining DBA access to the database. 

As mentioned in the above ORACLE DBMS, we find 
facilities to prevent incorrect data from being in a 
database and to prevent the reading of data that should not 
be disclosed to unauthorized personnel in the ROKAF's 


environment. 
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4. Data Dictionary 
PhevwORaclLe Gata dictionary 1S a group of tables that 


Goncain infOrmation about the database. These dictionary 
tables are created by ORACLE at the time the database is 
emeaced. the dictionary describes tables, indexes, clusters, 
Msers, access privileges and other things in the database. 
ORACLE automatically updates the dictionary whenever anyone 
@eeates Or drops a table or view and grants or revokes a 
Meavilege, so the dictionary always contains a current 
description of the database. 

Usemsscan read divetivonary tables using standard SQL 
queries and, since the dictionary is "self describing," it 
can be queried to determine the names of its own tables, 
memumns, etc. Howéver, not all of the dictionary tables 
memwrews have the SELECT privilege granted to the public. 
Other tables, such as the one containing user passwords, are 
only accessible to someone with DBA privileges. The results 
of examples of selected dictionary queries are displayed in 
Pependix B-Part III. 

oe Report Generation 

immener personne! daceapase, all data in relation to 
personnel management are a variety of format types and 
prompt actions. The development of new personnel management 
techniques and the continuously changing requirements of 
each organization may require new formats or alternations of 


existing formats. If we do not need formal report 
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documentation, then the staff and management of each 
@ietanizgation Unit Can directly use the terminal display. 
Otherwise, we can use ORACLE report facilities which provide 
Pecommands £Or producing formatted reperts: 

1. Column - Format a column's heading and data 

mueleitie = Puc a title om the top of the page 

S. BTITLE - Put a title on the bottom of the page 

4. Break - Break the report up into groups of rows 

5. Compute - Compute subtotals and totals 

(MeomOUmOtIEEO tally ol Query Can be dutomatical ly 

formatted into a report with page and column headings and 
page numbers. Column headings and data formats are taken 
from the data dictionary. Users can request tables on 
@omergl breaks, alter report and column headings, and 
specify page size and column justification. The results of 


peemoles of selected queries are shown in Appendix B Part IV. 
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IV. CONCLUSIONS 


This thesis has focused on the Korean Air Force 
Headquarters and Command and Control, however its findings 
gee applicable to all departments of the Korean military. 
The developed database presented here is based on a 
relational database model and a computerized personnel 
management system for military officers only, however it may 
very well form the basis of the total personnel management 
system. 

in@sesthesis examined a stepwise design process for 
logical design of personnel database which covers: 

1. Collecting data relevant to personnel and analyzing 


PAeimots~anigdelon S cequlrements. 


tr.) 


hectmelbpyine all the engity and relationship types, and 
Gonstraings for each organizational area. 
3. Using normal forms based upon functional dependencies 
for eliminating anomalies and redundancy. 
4. Designing the database dictionary which communicates 
Between database designers and users. 
ivemaata dictionary was designed as a directory for the data 
aes included in Appendix A. 
Implementation of a prototype database using ORACLE 
melted in a more effective and timely presentation of all 


feaquared personnel information. This DBMS is particularly 
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BEppnopriate to the application programmers and end-users who 
are working in the ROKAF who do not have much experience 
with database systems. This database system can increase 
personnel management's efficiency and decrease staff work 
meadeas Well as reduce national defense expenditure. 

This database can serve as a prototype from which ROKAF 
@ageeretine @€xisting schemas and develop further applications 


ememeces report generation in the Korean language. 


68 


APPENDIX A 


DATA DICTIONARY 


feeb isl OF DATA ELEMENTS AND DOMAINS 
Miewrcereh A GcOnuLesponds tO alphanumeric, while the 
letter N corresponds to numeric. Each format number 


Beeeesents the maximum number of digits for a value range. 


ATTRIBUTE FORMAT REMARK 
eS 

AAP Nl assignment to a position 

ar E N3 imMenatemonaGge Of CrrIiclency point 

BOS N2 Dranch Of service 

BS N8 basic salary 

CD N8 commission date 

Cele N1 commission education course 

eS oRADE Nl capability grade 

COUNTRY N2 name of country 

CS N2 class standing 

CT N1 commission type 

DATE N4 year month day 

DC-ADVANCE N8 daecs On Gapabality ance 

DeGREE Nl graduate degree 

D-NAME A20 name of daughter 

D-OCCUP N2 daughter's occupation 

Dey Ni data point for promotion 
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MOT RIBUTE 


DPR 
DQ- ADVANCE 
D-RRN 
DUTIES 

ED 

ESD 

E-SN 
E-YEAR 

FA 


FMDR 


F-NAME 
ie CUP 
moe vi- AD 
BaRRN 


ERS 


BecREDIT 
few Gil 
IB 

LOC 

LSA 
MAJOR 
MD 


MDR 


FORMAT 


N8& 
N8& 


N15 


N7 


N4 


N7 
A20 
N7 
N2 


N8 


REMARK 


date of promotion 

date of quality advance 

RRN of daughter 

duties 

evaluated date of efficiency 
date of Scena ced supe. y 
service number of evaluator 
examination year 

family allowance 


final year of maximum duration at 
that rank 


name of father 
fPiene hr smeceuua E1on 
father's PM-AD 
Raho eraeie h 


final year of total required 
service duration 


se Gk eye exals hie 

height 

heen eCheew Denner 1 t 

Sieve stateroL Indication country 
long service allowance 

major course of education school 
marriage date 


maximum duration at that rank 
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Agi TBUTE 


M- NAME 
M-OCCUP 
MOS 
MOSA 
M-RRN 


MRS 


MS 
MTC-NAME 
NAME 

NOF 

OAG 
OCCUP 
OOP 

PD 

PE 
PERIOD 
PM- AD 

PP 

PR-AD 
Q-GRADE 
RANK 

RB 
R-DUTIES 
REASON 


FORMAT 


N2 


N16 


A40 


A40 
N1 
N2 
NO 
N3 

A50 


REMARK 


name of mother 

mother's occupation 

military occupational specialty 
MOS allowance 

RRN of mother 


maximum age for required service 
ae mide Gall 


marriage status 

ManiewOL Mitttary tralning course 
name of person 

number of family 

order of average grade 

tyne Of SeCeupa tion 

Sider .Oreprone t10n 

proficiency degree 

prerequisite education 

year month day (19801009-19831009) 
permanent address 

Hmereadils tee position 

present address 

quality grade 

rank of person 

regular bonus 

required duties 


type of reason 


fal 





iin (BUTE 


RE-DATE 
RESULT 
RRN 
SCHOOL NAME 
SD 

SEX 

of 

SN 

S- NAME 
s20CCUP 
SON NAME 
SON OCCUP 
SON -RRN 
e-PeERIOD 
o-PM-AD 
S-RANK 
S-RRN 

SS 

TAX 

TOAD 

TOB 

TOE 

oT 


OP 


FORMAT 


N8 
Nl 
N15 
Al0 
N8 


Az0 
N2 
N15 


REMARK 


regular examination date 
result status of training 
ene eiMtmne cs that LOMmmumbic © 
name of school 

Supplied date 

sex 

supply items 

Senvice Numnpe & 

name of spouse 

spouse's occupation 

name of son 

son's occupation 

RRN of son 

total serviced year 
spouse's PM-AD 

Stagus satrenat rank 

RRN of spouse 

salary step 

bax 

type of award/punishment 
blood type 

total number of evaluatee 
type of language 


type of promotion 


Ve 


Se re pgp ch yt i cee er ppg SP 





ATTRIBUTE FORMAT REMARK 


TOPM Al10 type of punishment 

TOV Nl type of vacation 

TRS Nl type of required service 
DY N2 CywwemOn ecemporany Cucy 
UNIT NAME N4 MameyOteam2litary unit 
WEIGHT N3 weight 


Meeeclsl! OF CODE NUMBER FOR DATA ELEMENTS 

Bact Os these tables contains two elements: code and 
Mescription. For instance, "01 General" indicates code 
mumoer is General. 


1. RANK/S-RANK: 


Opeeeemensd 1 U2 eee mMamcmGenle Gal 
03 Major General 04 Brigadier General 
Vsmeonone | 06 Lieutenant Colonel 
Q7 Major Vee Captain 


09 Second Lieutenant 10 First Lieutenant 
DPeiaiGrant Officer 
te SEX; 
1 Male Ze nenane 
See MIEITARY OCCUPATIONAL SPECIALTY: 
1111 supply ZA eeiveei Lt Cenee 


Moweaneluded= curly here for security reasons) 


“oS 





Oe 


COM iss t CONS SOURCE: 

1 AF Academy 2 WROTE 

(mot included fully here for security reasons) 
MARRIAGE STATUS: 

Ieiiann ved % Sy ipues dts 


ieeESOr RELIGION: 


1 Buddhist 2 Cakemolic 
3 Protestant 4 Other 
UNIT NAME: 


oie oe lth Trainings Wing 

Deze tiZZtneoupply Company 

(not included fully here for security reasons) 
NAME OF MILITARY TRAINING COURSE: 

111 Escape and Evasion 

Eee ocd Survival 


(not included fully here for security reasons) 


COMNIGERY : 

O01 USA O02 JAPAN 

03 ENGLAND 04 FRANCE 

0S UNBONESTA OS GREECE 

OTe aesiilP INES 08 CHINA 

09 GERMAN 10 CANADA 

DEGREE: 

ar EoMastwern Ss Wegree 


Seeaenelonr's Degree 
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apr 


ae 


eS. 


14. 


eS. 


16. 


17. 


Is . 


QUALITY GRADE: 

1 Low Quality 2 Medium Quality 

Seach OQualaty 4 Superior Quality 
GAPABIEITY GRADE: 

1 Low Capability 2 Medium Capability 

Seen Capabaliry 4 Superior Capability 
COMMISSION EDUCATION COURSE: 

1 AF Academy 2 Reserve officers’ training 
ieee OF REQUIRED SERVICE: 

1 Long Service 2 Short Service 


SUE iy ITEMS: 


01 Combat Shoe 02 Hat 
03 Gloves O04 Pants 
NS) Raincoat 06 Necktie 


(not included fully here for military security reasons) 
TYPE OF VACATION: 

l Regular vacation 2 Convalescent Leave 

3 Reward vacation 4 Emergency Leave 


mYeE OF LANGUAGE : 


iene lish 2 Japanese 
3° French 4 Chinese 
SeGeuman 

bEOOD TYPE; 

1A 2 8B 

520 4 AB 


ies 





isle 


m0. 


eat. 
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BO. 


24. 


tell 


TYPESOF PROMOTION: 

Pevecwl ar Pellet team OUS 

TapESOr FLIGHT: 

imemeincluded here for military security reasons) 
TRAINING REQUIREMENT: 

(not included here for military security reasons) 


RESULT STATUS OF TRAINING: 


1 graduate Piste traauate 

OCCUPATION: 

Ql] rtarming UZanaetonal public Service 
personnel 

Vem serviceman 04 education public service 

O05 commerce 06 fisheries 

07 student OSes & ry 


PooeaNvMeENT TO A POSITION/DUTIES/REQUIRED DUTIES: 
XXX company command 


(not included fully here for security reasons) 


THE RELATIONAL SCHEMA OF DATABASE DOMAIN 


Sec want li of data dictionary. 


RELATION 


i. 


PERSON (SN, RANK, NAME, RRN, MOS, PM-AD, PR-AD, CT, 
Cia Ss , BOS, RELIGION) 

Primary Key: SN 

IMMEDIATE FAMILY (SN, MD, S-RRN, S-NAME, S-PM-AD, 
SaeCCUemmOON-RRN. SON-NAME. SON-OCCUP, D-RRN, D-NAME, 
D-OCCUP) 


Primary Key: SN + MD 
76 





mo 


ae 


LINEAR FAMILY (SN, F-RRN, F-NAME, F-OCCUP, M-RRN, 
M-NAME, M-OCCUP, B-RRN, B-NAME, B-OCCUP, S-RRN, 
S-NAME, S-OCCUP) 

Primary Key: SN 

MitmisievkyY TRATNTNG {(SN> S-RANK, CS, RESULT) 

Primary Key: SN 

MILITARY TRAINING COURSE (MTC-NAME, PERIOD, UNIT 
NAME) 

Primary Key: MTC-NAME 

This subschema can be manipulated from 4 using DBMS. 
MILITARY CAREER (SN, UNIT NAME, S-RANK, APP, PERIOD) 
Pramanry Key: SN 

EDUCATION (SN, S-RANK, PERIOD, MAJOR, DEGREE, G-GRADE, 
DPP) 

Primary Key: SN 

EDUCATION COURSE (SCHOOL NAME, COUNTRY, LOC) 

Pmameny Key; SCHOOL NAME + COUNTRY 

Heweli CONDITION RECORD (SN, E-YEAR, RE-DATE, SEX, 
HEDGHT, WEIGHT, TOB) 

rigtmary sey: SN + E-YEAR 

AWARD/PUNISHMENT (SN, S-RANK, TOAP, DATE, DPP, REASON) 
Piicmy, Key: ON + TOAP + DATE 

AWARDED LIST (SN, NAME, DUTIES) 

Primary Key: SN + NAME 


This subschema can be manipulated from 10 using DBMS. 


Ly 





eZ. 


1s 


14. 


iS. 


fap 


ay 


eS). 


io. 


Ba). 


Zak 


Ze. 


PROMOTION POINT (TOAP, DPP) 

Primary Key: TOAP 

Powter NGy RECORD (oN, EDS) AG-E, TOE, OAG, E-SN) 
PranarveKey: SN + ED 

COMBAT QUALITY/TRAINING (SN, MOS, UNIT NAME, Q-GRADE, 
C-GRADE, DQ-ADVANCE, DC-ADVANCE) 

Primary Key: SN + MOS 

REGUTSLTESASSIGNMENT RECORD 

(not included here for military security reasons) 
This subschema can be manipulated from 14 using DBMS. 
PROMOGION EIST (SN, S-RANK, TOP, DPR, OOP) 

Prmmary Key; oSN 

ASSIGNMENT POLICY (UNIT NAME, RANK, R-DUTIES, MOS, 
PP, PE) 

Primary Key: MOS + R-DUTIES 

ReeUUREPeonRvIiCE (SN, FRS, MRS, MDR, FMDR) 

Primary Key: SN 

So Mlost ON LIST (CEC, TRS) 

Paamahy ney: CEC 

Teoma Ys DUTY (SN, TIDY, PERIOD, LOC, COUNTRY) 
Primary Key: SN 

Somer (oN; IB, TAX, RB) 

Primary Key: SN 

PA e@eoAbaARY (RANK, SS, BS) 

Paerilary skeyv. ~ RANK + SS 


This subschema can be manipulated from 21 using DBMS. 
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Zo. PAM AREOWANCE™ (NOF, FA) 

Prageany Key: 9NOF 

This subschema can be Manipulated from Zl wsing DBMS. 
ee eeeiiag SERVICE PERIOD (S-PERIOD, LSA) 

Primary Key: S-PERIOD 

This subschema can be manipulated from 23 using DBMS. 
25. MOS ALLOWANCE (MOS, MOSA) 

Primary Key: MOS 

This subschema can be manipulated from 21 using DBMS. 
meme VACATION LIST (SN, TOV, PERIOD) 

Primary Key: SN + TOV 
ee 6 POREIGN LANGUAGE PROFICIENCY (SN, TOL, PD) 

Pimimary Key: SN, TOL 
meee BROONNEL SUPPLY (SN, SI, SD, ESD) 

Puemacye Key: oN, SI 
aoe 6COWEPLY ITEMS 


(mot included here for security reasons) 


ieee OAMPLE LIST OF PROJECTED TRANSACTION 

iacse samples Of tCransaction-processing are very helpful 
memend user application system designers. For each 
Mmeamosaction, we identify its nature (retrieval, update, 
insert, delete), its frequency, its organization, and its 
purpose, together with the part of the schema it affects. 

As following in enterprise description in section B, we 
identify requirement for supporting transaction. Some of 


the relevant description are correspond to each number order. 


(es 





at. 


organizational area 

entity types and attributes 

relationship type 

eiemormdcceoom Toten levyel, update, delete, insert) 
Nedewer operation (batch, online) 

frequency (daily, weekly, monthly, yearly, required 
day ) 

—maoecesioime Priority (1, Il, III, V1) 

Seewnrty requirement (1, II, III) 

Remon LO Mia v 


A list of all new officers who are service number, 


momk, RRN, final education school name, major course, 


@eerec, Commission type, and whose MOS is 1111. 


JU 
cae 





9. 
RANK NAME S-NAME | MAJOR | DEGREE 


operation department 

PERSON (SN, RANK, MOS, RRN, CT) 
EDUCATION (SN, MAJOR, DEGREE) 
EDUCATION COURSE (SCHOOL NAME) 
PERSON - EDUCATION 

EDUCATION -EDUCATIONCOURSE 
Getmmre va | 

batch 

yearly 

IV 

I 








2. List of all combat crews who have some classified 
qualification, capability grade, and whose rank are captain. 
1. operational department 
2. PERSON (SN, RANK, NAME, MOS) 
COMBAT QUALITY/TRAINING (SN, MOS, UNIT NAME, Q-GRADE, 
C- GRADE) 
3. PERSON-COMBAT QUALITY/TRAINING 
me cetrieval 
eee batch 


6. required day 


ae CL 
ae |OCL 
ge 





UNIT NAME 






Seenverage Ot Classified flying of all combat crew 
based on certain rank, quality and capability grade, annual 
period, and organizational unit. 

ime Operational department 

2. PERSON (SN, RANK) 
COMBAT QUALITY/TRAINING (SN, UNIT NAME, Q-GRADE, 
C- GRADE) 
REO ENG erULELODNESS RECORD (TYPE OF FLYING, 
FLYING TIME) 

3. PERSON-COMBAT QUALITY/TRAINING 


Cove OUAimnt ly REQUIREMENT FULFILLNESS RECORD 
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4. retrieval 


Bey bateh 
6. monthly 
a | Cd 

Ss. | 

9. 


UNIT NAME | Q-GRADE | C-GRADE AVERAGE TIME 





waeerodeemlise Of ail retired person whose MOS was 111] 
mieluding present address, age. 
1. personnel department 


Pee ee RSON (ON, NAME, PRESENT ADDRESS, RETIRE STATUS, 


MOS, RRN) 
3. PERSON 
4. update 
Se batch 
6. monthly 
iy rast 
8 eel 


eN) | NAME JPRESENT-ADDRESS | RRN 
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APPENDIX B 


SAMPLE QUERIES OF ORACLE IMPLEMENTATION 


meee TABLE OPERATION 
A. CREATING TABLES 


1. Create a table named PERSON. 


UFI> CREATE TABLE PERSONC(CSN NUMBER(6),RANK CHAR(10),NAME CHAP(10), 
e€ MOS NUMBER(S),CD CHAR(10),CT NUMRER(3),4M5 NUMBER(3)); 


Table created. 


oe Insert three data into table named PERSON. 
UFI> INSERT [TO PERSON VALUES(234567, "COLONEL", 'CHA,S.H.',111, 
e "L1"©MAR-65',1,1)3 
1 record created. 


UFIT> INSERT INTO PERSSON VALUES (245678, 'MAJOR','KIM,K.S.' 121, 
2 "20-APR-H6',1,1)3 


1 record created. 


DET IMSERT TNO PEXSON VALUES( 255001, "MAJOR',*PARK,S.U.",130, 
Eel SE°=66 4 1,2)5 


1 eecord created. 


53. List the PERSON table. 


UFI> SELECT * FROM PERSON; 
SN RANK NAME MOS CO cT MS 

234567 COLONEL CHA,S.H. 111 1L1L=MAR=65 1 1 
245678 MAJOR KIM,K.S. 121 20-APR-65 1 1 
245001 WAJOR PARK,S.U. 130 21-SEP-66 1 2 


B. MANIPULATION OF TABLE 
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Paging saenew column to an existing table. 


Vi Vicia wemorricen'’ Securrent salary 


UE te oemecr « FROM SALARY? 

SN SSTEP [3 RB BS 
234567 e 200 1000 960 
245678 5 170 680 820 
24asoit 2 170 800 710 
290000 2 500 480 
256000 S 960 700 650 
214i! * 200 1200 1100 
214000 i) 200 1250 1200 
290123 1 450 410 


8 records selected 


QZ: Add a column TAX to the SALARY table. 


UPI SAETER  TASLE SALARY 
2 ADD (TAX NUMBER); 


Table altered 


CiritSe wleronunk: table. 


UR I> SEEECT * FROM SALARY; 
SN SSTEP [8 RB 3S TAX 
234567 2 200 1000 960 
245678 5 170 880 820 
245011 2 170 800 710 
290000 2 $00 480 
256000 5 960 700 650 
214111 ~ 200 1200 1100 
214009 5 200 1250 1200 
290123 1 450 410 


8 records selected, 


Updating rows in a table 


Cue Last isemvace number 234567's Current salary. 


UE SELECT * FROM SALARY WHERE SN = 2345677 
SN SSTEP rs RB BS TAX 
234567 a 290 1234 960 
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te SCcemservice mumbper 254507's regular bonus 


(Rp ee ore 0 


UF I> UPMATE SALARY 
2) Sew RB = 1400 
3 WHERE SN = 2345673 


1 record updated. 


DO we vetrNe tat service number 25456/7's 


Regular Bonus (RB) has been updated. 


UFT> SELECT # FROM SALARY WHERE SN = 234567; 
SN SS rer TB RB BS TAX 
234567 Pad 200 1400 960 


(lore thing Lows £rom a table. 


CF ee Pe elem oN EARY “tabiex 


vers SELECT & FROM SALARY; 
SN SSTEP 18 RB BS TAX 
234567 2 200 1234 960 
245678 5 170 880 820 
2450 va 170 800 710 
290000 2 $090 480 
256000 5 960 700 650 
214iii 4 200 1200 1100 
214000 S cd 1250 1200 
290123 1 450 G10 


8 records selected. 


Oe eeletete seruice number 254560/'s row from 


le ocak veep le. 


UFIT> DELETE FROM SALARY WHERE SN = 2345673 


1 record deleted. 
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eee ese Elle pOALARY suaple. 


UES SELECT * FROM SALARY; 


SN SSTEP 13 RB BS TAX 
245678 5 170 B80 820 
245011 2 170 B00 710 
290000 2 500 480 
256000 S 960 700 650 
244111 4 200 1200 1100 
214000 5 200 1250 1200 
290123 1 40 410 
7 recoras seiecte 
meee RELTRIEVAL OPERATION 
A. GENERAL OPERATION 
i Selecting data from a Table. 
OU eee leGem oN / RANK NAME, and MOS of all 
officers from the PERSON table. 
UFI> SELECT SV,RANK,NSME,MOS FROM PERSON; 
SN RANK JAME MOS 
234567 COLONE GH8,S.H. 7 
245n7A MAJOR KIM,K.S. 121 
225011 MAJOR PARK,S.U, 130 
220000 LIEUTENANT LIM,S.N. 111 
244111 COLONEL JANG,ULL. 130 
279123 LIEUTENANT UI,C.H. 222 
PSo00N) CAPTAIN CHU,K.S. 111 
214000 COLONEL YOON, I.S. 121 
eee ce ceeilcmspeelric ROWS trom a Table. 
Qli: Select only all officers whose MOS is 111. 
UFI> SELECT s FROM PERSON WHERE MOS = L117 
3N RANK NAME MOS CD eT MS 
290000 LIEUTENANT LIM,S.N. 111 16=YAY=80 2 2 
250000 CAPTAIN CHU .%..S. 111 11-FEB=67 1 2 
234567 COLONEL CHA,S.H. 111 L1-VAR=65 1 1 
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Oh: Famdmol, RANK, and NAME of all officers 


With regular bonus (RB) greater than 


ONO. 


UFI> SELECT SN,SSTEP,IB,28 FROM SALARY WHERE RB > 1000; 


Si Soler fs RB 
014111 4 200 1290 
214000 5 200 1250 


3. Selecting Rows that satisfy Multiple Conditions. 
O13: bist SN, RANK, and NAME of all officers 


whose MOS is 111 and MS is l. 


UrI> SELECT SN,RANK,NAME FPOM PERSON WHERE MOS = 111 


AND MS = 1? 


234567 COLONEL CHA,S.H. 


4. Selecting Rows within a certain range. 
Q14: Find SN, RANK, NAME, and RB of all 


officers whose regular bonus is between 


$700 and $900. 


FI> SELECT PERSON.SN,RANK,NAME,R&B FROM SALARY,PERSON 
@ WHERE PERSON.SN = SALARY.SN 


3 AND RB BETWEEN 700 AND 9003 


SN RANK NAME 


RB 
20sec, 2 MAJOR oie ce 880 
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UF I> 


Welt Ime Search Condition. 

Gls ees cron AN iow name, IB, BS, and RB of 
all officers who do not receive IB. 

SELECT PERSON.SN, RANK, NAME,IB,RB,BS FROM SALARY,PERSON 


NHERE PERSON.SN = SALARY.SN 
ANO 18 IS NULL; 


SN RANK NAME 18 RB BS 
290000 LIEUTENANT LIM,S.N. 500 480 
290123 LIEUTENANT UI,C.H. 450 410 


Ordering Rows of a Query Result. 
OnG- was teo.. RANK NAME, IB, and RB of all 
officers who do not receive IB and in 


Onder Dy Eneir RB. 


SELECT PERSON.SN,RANK,NAME,1B8,8S,RB FROM PERSON, SALARY 
WHERE PERSON.SN = SALARY.SN 

ANO [8 IS NOT NULL 

ORDER BY RB? 


SN RANK NAME 8 BS R8 
256000 CAPTAIN CHU,K.S. 960 650 700 
245678 MAJOR KI4,K.S. D0 B20 840 
234567 COLONEL CHA,S.H. 200 960 1000 
P141tt COLOWEL JANG,U.T. 200 1190 1200 
214000 COLONEL YOON, IT.S. 200 1200 1250 


5 records selected, 


GROUP FUNCTION 


Q17: Find the average basic salary for 'COLONEL'. 


UFT> SELECT AVG(RS) 
2 FROM SALARY,PERSON 
3 WHERE PERSON.SN = SALARY.SN 
G@ AND RANK = "*COLONEL’? 


AVG(8S) 


eeeen @e 2 ws @ & 


1086.60667 
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Chiweiseetic number of orficers whose MOS 


Sel: 


UF I1> SEEECT COUNT (Cs) 
2 FROM PERSON 
S=4WHERE “40S = Pils 


COUNT ( *#) 


eGaewwewwee@e wv @ 


3 


Cee OLN ING TWO OR MORE TABLES. 
Poo Lec timom@dud trom two of more tables and 
equijoin. 
OL weeindeas ttn ana NAME of all officers 
from the PERSON table and IB, RB, and BS 


Cpt heortmeers strom the SALARY table. 


UFI> SELECT PERSON.SN',RANK,NAME,I8,8B,8S 
2 FROM PERSON, SALARY 
3 WHERE PERSCON.SN = SALARY.SN? 


SN RANK NAME 18 R8 BS 
234567 COLONEL CHA,S.H. 200 1000 960 
245678 MAJOR KIM,K.S. 170 880 820 
2970000 CIEVUIENANT LIM,ZS.N. 500 480 
256000° CAPTAIN CHU,K.S. 960 7900 650 
Oer4iiti COLONEL JANG,U.I. 200 1200 1100 
214000 COLONEL YOON, 1.5. 200 1250 1200 
eo0e Ss EuEUTENANT (UL, CCH. 45d 410 


7 records selected. 
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Zee Outer -John 


O20: 


List SN, RANK, NAME and BS of all officers 
who have received IB and in order by their 


service number. 


UFT> SELECT PERSON.SN,RANK,NAME,BS 


Oo FROM PERSON, SALARY 

3 WHERE PEQSON.SN = SALARY.SN( +) 
4 AND SALARY.IB IS NOT NULL 

S ORDER BY PERSON.SN; 

SN WANK NAME BS 
2140900 COLOVEL YOON, 1.9. 1200 
2e14iitl COLONEL JANG,U.IT. 1100 
234557 COLONEL CHAa,S.H. 960 
2USo7A MAJOR KIM,«.S. 829 
256000 CAPTAIN CHU,K.S. 659 


S records selected. 


Preeco OUND QUERIES WITH MULTIPLE SUBQUERIES 


OZ: 


List RANK, NAME, MOS, and BS of all 
officers who have the same MOS as 


'CHA, S. H.'. 


UFI> SELECT RANK,NAME,(40S,-B8S 


2 FROM PERSON, SALARY 

3 WHERE PERSON.SN = SALARY.SN 

GQ AND MOS IN 

) (SEGUE ie 05 

6 FROM PERSON 

7 WHERE NAME = °CHA, S$. Hw") 
RANK NAME “0S BS 
EJLONEL CHA,S.H. 111 960 
LIEUTENANT LIM,S.N. 111 480 


CAPTAIN CHU,K.S. 111 650 
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Mit. DATA DICTIONARY 
voeievolbeo TikttevESeRTBEVOLHER TABLES. 


7 ees erence tables thn created. 
UFI> SELECT * FROM TAB? 


TNAME TABTYPE 


AA TABLE 
CTYPE TABLE 
FEP TABLE 
MSTATUS TABLE 
PERSON TABLE 
PERSON1 TABLE 
SALARY TABLE 
TOL TABLE 


8 records selected, 


The dictionary table TAB contains the names and 
descriptions of all the tables, views, synonyms and clusters 
Mmaaentiser have Created. Since user are logged on as user 
CHA, user see the tables CHA has created 

Q23: List all the tables and views that CHA 

asp Lees On . 


UFI> SELECT * FROM CATALOG; 


TNAME CREATOR TABTYPE TABID 


AA CHA TABLE 26113 
CTYPE CHA TABLE 26629 
ELP CHA TABLE 27137 
MSTATUS CHA TABLE 27649 
PERSON CHA TABLE e8161 
PERSON! CHA TABLE 286753 
SALARY CHA TABLE 29185 
TOL CHA TABLE 29697 


8 records selected. 


The CATALOG list includes the other tables that 
were created by other user but on which CHA has access 
privileges. But even the CATALOG list is not complete 


Beeause 1t does not contain table from the dictionary. 


oa 





Oe: 


UFI> SELECT * FROM SYSCATALOG; 


TNAME 


DUAL 
STORAGE 
EXTENTS 
SPACES 
SYSCOLUMNS 
COLUMNS 
SYSCATALOG 
CATALOG 
SYSINDEXES 
INDEXES 
VIEWS 
SYSTASAUTH 
TAB 

COL 

EXPTAB 
EXPVEA 
DTAB 

AA 

CTYPE 

FLP 
MSTATUS 
PERSON 
PERSON! 
SALARY 

TOL 


2b records selected. 


CREATOR 


SYSTEM 
SYSTEM 
SYSTEM 
SYSTE™ 
So eM 
So TEM 
SYSTEM 
SYSTEM 
SYSTEM 
SYSTEM 
Sy oem 
SYSTEM 
SYSTEM 
SYSTEM 
SYSTEM 
SYSTEM 
System 
SYSTEM 
CHA 
CHA 
CHA 
CHA 
CHA 
CHA 
CHA 
CHA 


Gendt ctioOnany. 


TABTYPE 


lsteall! CHA*s tables and view including 


TABID 


TABLE 
TABLE 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEW 
VIEw 
VIEW 
VIEn 
VIEW 
VIEW 
TABLE 
TARLE 
TABLE 
TABLE 
TABLE 
TABLE 
TABLE 
TABLE 
TABLE 


9985 
10897 
11520 
11776 
12288 
12544 
12800 
13056 
13312 
13568 
13824 
14080 
14336 
14848 
15104 
15360 
15616 
15873 
26113 
26625 
27137 
27689 
28161 
28673 
29185 
29697 


The dictionary table SYSCATALOG includes all 


maples including the dictionary. 
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ive REPORT GENERATION 

o> eons Benes Neaaime Of Cach Column to two 
Cen Omemlilcow lt ene title= of OrriICER 
Pele eke Gueak REPORT on Separate lines 
at the top, and CONFIDENTIAL at the bottom 


of each page of the report. 


Pepe TIITLE “OFFICER LIST? {REGULAR REPORT’ 
UF I> BTITLE ‘CONFIDENTIAL’ 
UFI> COLUYN SN HEADING 'SERVITE NUMBERS 
UPT> COLUMN MOS HELDING “MIL TTAR YI OCCUPATIONAL? SPECIALTY’ 
UFI> COLUYN CD HEADING ‘COMMISSIONS DATE’ 
Pete COLUYN CI HEADING *°COMMISSIONS TYPE ° 
UFIT> COLUMN MS HEADING *MARRIAGE! STATUS’ 
WEt> SELECT * 
ec FROM PERSON 
3 ORDER BY SN; 


Tue Seo 13 page 1 
OFRICER -LIS 


REGULAR REPORT 


MILITARY 
SEPVICE OCCUPATIQNAL COMMISSION COMMISSION MARRIAGE 
NUMBER RANK NAME SPECIALTY DATE TYPE STATUS 
214000 COLONEL YOON, 1.65. 121 17*DEC=63 Pa 1 
214331 COLOVEL JANG,U.I. 130 ec4=JUN-64 1 1 
234567 COLQNEL CHAT S.6 Te 11} LPeVARe65 i 1 
245001 “AJNR PAKK sg Sal. 130 21+SEP-66 1 2 
245678 VAJIOR Rolie 6 Lol 20-APR-66 1 1 
2560000 CAPTAIN CHUCK CS. L111 11°0CT=68 2 1 
290000 LIEUTENANT LIM,S.N. L111 lto-JAN=70 1 2 
290123 LIEUTENANT UI,C.H, eee 05-SEP-71 2 2 

CONFIDENTIAL 


8 records selected. 


W2o-eeewertne citle or MONTHLY - PERSONNEL REPORT 
on separate lines at the top of each page 
Blasts Service number, Pon eeiiecl lt cence 
benefit, regular bonus, and basic salary 


Oteal)l Orricers. 


UE Vos TTITEE "MOMTRLY SALARY ISERSONNEL REPORT * 
Uel> COLUMN SSTEP HEADING “SALARY; STEP’ 
Hel> cOEUMN 18 READING "INTELLIGENCE {BENEFIT 
UFIT> COLUMN RB HEADING ‘REGULAR; RONUS ' 
UF I> COLUMN BS HEADING ‘S4STCISALARY® 
mie seeee!l PERSONISN, RANK, NAME, IB, RBs. BS 
ec FROM PEFSOMN, SALARY 
3 wAHERE PERSON.JSN = SALARY.SNS 


Tue Sep 13 cage 1 
MOMTHLY SALARY 


PERSONNEL REPORT 


SERVICE Pte TGbnce REGULAR BASIC 
NUMSER RANK NAME BENEFIT BONUS SALARY 
234567 COLONEL Sines yalale 200 1000 960 
°C4S5078 MAJOR KIM,K.S. 170 880 820 
245001 MAJOR PaRK,S.U. 170 800 710 
290000 LIEUTENANT LIM,S.N. 500 480 
2560000 CAPTAIN CHU,K.S. 960 700 650 
214yii COLONEL JANG,U.T. 200 1200 1100 
214000 COLONEL YOON,1.S. c00 1250 1290 
eo0tes LIEUTENANT UI,C.H. 450 410 


8 records selected. 
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